Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(txpool): only try demoting txns from accounts that were active #30480

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

omerfirmak
Copy link
Contributor

@omerfirmak omerfirmak commented Sep 20, 2024

txpool demotes pending txns only if their nonce is now lower than the nonce in the latest state 
or the account no longer has enough funds to cover the costs. Unless the account in question 
was active since the last txpool reorg, there is no way that it's nonce changed or balance decreased.

for time periods where txpool is heavily congested, demote can take multiple seconds due to all the state access that it needs to do per pending txn account.

txpool demotes pending txns only if their nonce is now lower than
the nonce in the latest state or the account no longer has enough
funds to cover the costs. Unless the account in question was active
since the last txpool reorg, there is no way that it's nonce changed
or balance decreased.
@jwasinger
Copy link
Contributor

From a glance, it appears the IO overhead is per account in the pending set (balance + nonce lookup). not per tx.

@rjl493456442
Copy link
Member

I think it might be a reasonable change. Have you ever estimated how much performance gain we can have with this change?
Or do you know what's the ratio between the all pending accounts and the active accounts?

@omerfirmak
Copy link
Contributor Author

omerfirmak commented Sep 25, 2024

I think it might be a reasonable change. Have you ever estimated how much performance gain we can have with this change? Or do you know what's the ratio between the all pending accounts and the active accounts?

I don't have numbers on ETH mainnet, but on Scroll this change brought demoteUnexecutables runtime from ~800msecs to ~15msecs with roughly 28k pending txns. But keep in mind Scroll blocks are significantly smaller (~80Txns)

@fjl fjl self-assigned this Sep 26, 2024
@karalabe
Copy link
Member

karalabe commented Oct 1, 2024

We've discussed this a bit on triage today, but figured we'll let it marinate a bit more. One one hand we agree that it's a meaningful optimization and it's already something we do in the blobpool. On the other hand, the current code has a bit of self-corrective behavior if some invariant breaks internally, whereas the proposal requires a much higher degree of correctness.

Wondering if it would be a saner approach to move out the unexecutables into a limbo and redesign the pool from scratch. It's something we've always wanted to do but it's not really a quick thing at all. Lets ponder about it a bit more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants